An extended bridge is a network topology that is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.1BR standard and comprises two different types of units: a controlling bridge (CB) unit and one or more port extender (PE) units. The CB serves as the controller of the extended bridge and is responsible for performing control plane functions (e.g., Layer 2 switching, Layer 3 routing, etc.) with respect to network traffic that passes through the extended bridge. In contrast the PEs, which connect to the CB and to other network devices/hosts external to the extended bridge, act as non-intelligent devices and thus do not perform any local switching or routing; instead, their primary function is to provide additional data port terminations for the CB. For example, each PE may be a switch/router with X number of physical data ports, which appear as virtual data ports on the CB. Upon receiving a data packet from an external device/host on an ingress data port, the PE forwards the data packet to the CB, which processes the data packet in hardware and/or software to determine an appropriate egress port of the extended bridge through which the packet should be sent out. The CB then forwards the data packet to the PE housing the egress port for transmission through that port towards the next hop destination.
The links that interconnect the PEs to each other and to the CB in an extended bridge are known as cascade links. These cascade links are considered internal to the extended bridge since they only carry network traffic that has been tagged with a special ETAG header that is understood by the PEs and CB. The ETAG header facilitates the internal routing of traffic from an ingress PE to the CB for processing, as well as from the CB to the egress PE(s) that will forward the traffic out of the extended bridge. A PE may connect directly to the CB or may connect indirectly to the CB via one or more intermediate PEs. For example, multiple PEs may form a chain with one end, or both ends, connected to the CB. In the case where both ends of a PE chain are connected to the CB, the PE chain is referred to as a PE ring.
Generally speaking, PEs may join (i.e., be physically attached to) and leave (i.e., be physically detached from) an extended bridge at any time. When a PE joins the extended bridge, the CB generates and stores configuration information for the PE that enables the CB to integrate the PE into the extended bridge and to manage the PE's operation. As part of this process, the CB must assign an identifier, known as a PE ID, to the joining PE so that the CB can reference the PE in its configuration. For example, the CB typically represents the ports of a PE using the format x/y/z, where x is the PE ID, y is the PE I/O module (if applicable), and z is the port number. Thus, the CB must know what the PE ID for the PE should be before it can generate and store x/y/z-based port configurations.
One known method for performing PE ID assignment involves requiring a user to enter, on the CB, the hardware serial number or MAC address of each PE that is part of the extended bridge. The CB then uses these serial numbers or MAC addresses as the PE IDs. However, this method is inconvenient because the user needs to first find the serial number or MAC address of each PE (by, e.g., physically inspecting the PE device label) before he/she can enter it on the CB. In addition, this method does not work for “unit replacement,” which is a scenario where an existing PE unit in the extended bridge is replaced with a new PE unit of the same type/model. In the case of unit replacement, the new PE will serve the same role as the original PE, and thus the new PE should have the same configuration and same PE ID as the original PE. However, this is not possible if the PE IDs are based on hardware-specific serial numbers or MAC addresses, since these serial numbers/MAC addresses will necessarily be different for each unit.
Another known method for performing PE ID assignment involves requiring a user to enter, on the CB, a single user-defined PE ID for each port of the CB. For example, the user may enter PE ID X for CB port P1, PE ID Y for CB port P2, and so on. This user-defined PE ID is then assigned to the PE connected the CB port. However, this method also suffers from a number of limitations. First, since it requires the user to manually enter the PE IDs (rather than automatically generating them), the user must figure out which PE IDs use. Second, since the user can only enter a single PE ID per CB port, this method is limited to extended bridge topologies in which a single PE is connected to each CB port, and thus does not support topologies with chains/rings of PEs. Third, this method does not allow the user to easily implement “PE movement,” which involves moving a PE to a different location in the extended bridge (e.g., connecting it to a different CB port) while at the same time keeping the PE's originally assigned ID. To implement PE movement using this assignment method, the user must detach the PE, change the CB port-level configuration, and then reattach the PE, which can be a tedious process.